CMake modern create translations - #8062

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

To avoid the clang-tidy warnings we need to disable all checks. See at the top of gui/CMakeFiles.txt (that should be moved into a shared function since it already used in another place).

Thanks for you explanation. I don't get which folder needs the additional clang-tidy configuration file. My change does not add generated files in a new directory, does it?

I see no reason to hold this back. Please consider merging.

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

I don't know much about cmake and asked AI to review this. In my experience AI reviews are often mostly wrong - take this AI-review below with a mountain of salt:

The deprecation claim checks out. Qt's own docs for qt_create_translation state it's deprecated in favor of the target-based qt6_add_lupdate/qt6_add_translations (Qt docs
(https://doc.qt.io/qt-6/qtlinguist-cmake-qt-create-translation.html)). (Note: the PR title/body says QT_CREATE_TRANSLATION, not QT_TRANSLATE_TRANSLATION — I assume that's what you meant.)
qt_add_translations needs Qt ≥6.2, and this repo already requires Qt6 everywhere in CI (including the "oldest supported" ubuntu-22.04 job, which already has
qt6-l10n-tools/qt6-tools-dev-tools installed), so there's no version-compatibility issue.

But the patch drops something it doesn't replace. The old code did:
QT_CREATE_TRANSLATION(qms ${CMAKE_CURRENT_SOURCE_DIR} ${tss})
...
install(FILES ${qms} DESTINATION ${CMAKE_INSTALL_BINDIR} COMPONENT applications)
The PR removes the QT_CREATE_TRANSLATION(qms ...) call but leaves install(FILES ${qms} ...) untouched (gui/CMakeLists.txt:75 in the PR). Nothing sets qms anymore, so that install line now
installs an empty file list — the built package ships with zero .qm translation files.

This isn't cosmetic: gui/translationhandler.cpp loads translations from disk at runtime (QFile::exists(datadir/lang/...), mTranslator->load(...)), not from a Qt resource.
qt_add_translations by default embeds generated .qm files into a compiled-in Qt resource (prefix /i18n) instead of leaving them as loose files — getting standalone .qm paths back requires
explicitly passing QM_FILES_OUTPUT_VARIABLE, which the PR doesn't do.

There's also direct corroborating evidence in the repo: .github/workflows/release-windows.yml does
move build\gui*.qm win_installer\files\translations
expecting loose .qm files under build/gui/, matching the old mechanism. That workflow only runs on release tags / nightly schedule / manual dispatch — not on this PR's own CI — so this
breakage wouldn't be caught before a release.

Minor secondary note: the PR deletes the comment # TODO: passing "-no-obsolete" here breaks the translations and then passes LUPDATE_OPTIONS "-no-obsolete" anyway. That's probably fine in
practice since qt_add_translations only runs lupdate via an opt-in update_translations target (not part of the default build, unlike the old always-on macro) — but the reasoning that
flag was avoided for is no longer documented anywhere, so it could resurface if someone runs that target to refresh translations later.

Verdict: moving off QT_CREATE_TRANSLATION is the right direction, but this PR isn't a correct/complete fix — it needs to wire qms/QM_FILES_OUTPUT_VARIABLE back into the install() call and
verify where qt_add_translations actually places .qm files relative to what release-windows.yml expects, before merging.